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DETAILED ACTION 

Response to Arguments 

1. Please note AU 2616 is now AU 2416. 

2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 10/01/2008 has been entered. 

3. Applicant's arguments, see page 7, filed 12/2/08, with respect to the rejection(s) of 
claim(s) 1-5, 8-12, 15-17, and 19-21 under 103 have been fully considered and are persuasive. 
Therefore, the rejection has been withdrawn. However, upon further consideration, a new 
ground(s) of rejection is made in view of new reference Allison et al. (US 6,393,457). 

Claim Rejections - 35 USC §103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 1-5, 8-12, 15-17, and 19-21 are rejected under 35 U.S.C. 103(a) as being obvious 
over Hayes (US 2003/0158906) in view of Connery et al. (US 6,246,683) further in view of 
Allison et al. (US 6,393,457). 
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In regards to claim 1 , Hayes discloses a method of processing frames for a TCP 
connection comprising: processing a first portion of the frames using an offload unit to produce 
first processed frame data (figs. 7 and 12 disclose an offload processor. Paragraph 38 discloses 
offloading a portion of the frames for processing); processing a second portion of the frames 
using the offload unit to produce second processed frame data (figs. 7 and 12 disclose an offload 
processor. Paragraph 38 discloses offloading a portion of the frames for processing); and 
processing the second processed frame data using the TCP stack executed on a CPU to produce 
third processed frame data (Paragraph 39 discloses sending some frames back to the CPU for 
further processing using the TCP stack if the offload processor cannot complete the processing.) 

Hayes is silent to uploading the first processed frame data to a user buffer in a first 
portion of memory that is allocated to an application program; and uploading the second 
processed frame data to a legacy buffer in a second portion of the memory that is allocated to a 
software driver configured to communicate between the offload unit and a TCP stack. 
Additionally, Hayes is silent to receiving a user buffer descriptor specifying a location of a 
plurality of user buffers in a first portion of memory that is allocated to an application program, 
wherein each user buffer is configured to store processed frame data for the delegated TCP 
connection; and indicating in a filed of the user buffer descriptor how many of the user buffers 
store the first processed frame data for the delegated TCP connection. 

Connery discloses uploading the first processed frame data to a user buffer (fig. 4 
element 111 discloses a buffer) in a first portion of memory that is allocated to an application 
program (fig. 4 indicates the buffer, 1 1 1, is located in a higher layer managed memory. Col. 6 
lines 41-44 disclose it is an application managed memory.) and uploading the second processed 
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frame data to a legacy buffer (fig. 4.1 10 discloses a buffer) in a second portion of memory that is 
allocated to a software driver (fig. 4 indicates the buffer, 1 10, is located in a driver managed 
memory) configured to communicate between the offload unit and a TCP stack (fig. 3 discloses 
the driver layer, 54, communicates between the offload unit, 56, and a TCP stack, 52.). Connery 
discloses passing identification of a target buffer as a buffer descriptor including an address and 
length in col. 5 lines 1-6. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to upload the first and second portion to buffers in application or driver memory respectively, as 
taught by Connery, in the offloading method taught by Hayes because doing so improves the 
performance and scalability of a network, as taught by Connery in col. 3 lines 4-10. 

Allison discloses a buffer count field in a user buffer descriptor in fig. 3 and col. 5 lines 
51-60. The field indicates the number of buffers which contain data. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include a buffer descriptor with count field, as taught by Allison, in the offload method taught 
by Hayes because doing so helps provide architecture capable of speeds from 10-1000 Mbps, as 
taught by Allison in col. 2 lines 15-17. 

In regards to claim 2, Hayes and Connery disclose the method of claim 1, further 
comprising determining whether a special case exists during the processing of each of the frames 
(Hayes p. 38 discloses determining if an "exceptional condition", in other words a special case, 
exists during processing.) 
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In regards to claim 3, Hayes and Connery disclose the method of claim 1, wherein at least 
a portion of the first processed frame data is payload data (Connery fig. 4. 102 discloses the first 
portion consists of payload data.) 

In regards to claim 4, Hayes and Connery disclose the method of claim 1, wherein at least 
a portion of the second processed frame data is partially processed frame header data (Connery 
fig. 4.101 discloses the second portion consists of header data.) 

In regards to claim 5, Hayes and Connery disclose the method of claim 1, wherein at least 
a portion of the second processed frame data is payload data (Connery fig. 4.101 is termed a 
header fragment. However, it is disclosed the fragment is made up of Ethernet, IP, TCP, and 
SMB headers. As each header is added it is common to consider the remainder of the packet as 
payload. In other words, the Ethernet header encapsulates a payload which also happens to 
include IP, TCP, and SMB headers.). 

In regards to claim 8, Hayes and Connery disclose the method of claim 1, further 
comprising finishing processing of the second processed frame data by the TCP stack executed 
on the CPU (Hayes p.39 discloses finishing processing by the TCP stack on the CPU if the 
offload processor cannot complete processing. Connery fig. 3 and col. 6 line 58 - col. 7 line 20 
disclose completing processing of the second processed frame conventionally, using the TCP 
stack.). 

In regards to claim 9, Hayes discloses a system for processing data for a TCP connection, 
comprising: a TCP stack (fig. 10.1 18 discloses a conventional TCP stack) configured to process 
received frames (p. 39 discloses processing certain receiving frames using the conventional TCP 
stack); a software driver configured to interface between the TCP stack and an offload unit (fig. 
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10. 116 and 160 are device drivers which interface between the TCP stack and offload unit.); and 
the offload unit (fig. 10.26c is the offload unit) configured to: process frames received on a 
delegated connection to produce pay load data and partially processed frames (figs. 7 and 12 
disclose an offload processor. Paragraph 38 discloses offloading a portion of the frames for 
processing). 

Hayes is silent to a memory configured to store user buffers in a first portion that is 
allocated to an application program and to store legacy buffers in a second portion that is 
allocated to the software driver; and uploading partially processed frames to at least one of the 
legacy buffers; and upload the payload data to at least one of the user buffers. Additionally, 
Hayes is silent to receiving a user buffer descriptor specifying a location of a plurality of user 
buffers in a first portion of memory that is allocated to an application program, wherein each 
user buffer is configured to store processed frame data for the delegated TCP connection; and 
indicating in a filed of the user buffer descriptor how many of the user buffers store the first 
processed frame data for the delegated TCP connection. 

Connery discloses uploading the first processed frame data to a user buffer (fig. 4 
element 111 discloses a buffer) in a first portion of memory that is allocated to an application 
program (fig. 4 indicates the buffer, 1 1 1, is located in a higher layer managed memory. Col. 6 
lines 41-44 disclose it is an application managed memory.) and uploading the second processed 
frame data to a legacy buffer (fig. 4.1 10 discloses a buffer) in a second portion of memory that is 
allocated to a software driver (fig. 4 indicates the buffer, 1 10, is located in a driver managed 
memory) configured to communicate between the offload unit and a TCP stack (fig. 3 discloses 
the driver layer, 54, communicates between the offload unit, 56, and a TCP stack, 52.). Connery 
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discloses passing identification of a target buffer as a buffer descriptor including an address and 
length in col. 5 lines 1-6. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to upload the first and second portion to buffers in application or driver memory respectively, as 
taught by Connery, in the offloading method taught by Hayes because doing so improves the 
performance and scalability of a network, as taught by Connery in col. 3 lines 4-10. 

Allison discloses a buffer count field in a user buffer descriptor in fig. 3 and col. 5 lines 
51-60. The field indicates the number of buffers which contain data. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include a buffer descriptor with count field, as taught by Allison, in the offload method taught 
by Hayes because doing so helps provide architecture capable of speeds from 10-1000 Mbps, as 
taught by Allison in col. 2 lines 15-17. 

In regards to claim 10, Hayes and Connery discloses the system of claim 9, wherein the 
offload unit is configured to process frames for which a special case does not exist (Hayes p. 39 
discloses returning frames from the offload to the main processor if a special case exists. In 
other words the offload unit only processes frames for which a special cases does not exist.). 

In regards to claim 11, Hayes and Connery disclose the system of claim 9, wherein the 
offload unit is configured to notify the TCP stack when a special case is determined to exist 
(Hayes p. 39 discloses transferring control back to the TCP stack, from the offload processor, if a 
special case is determined to exist. The transfer of control serves as notice to the TCP stack of 
the special case.). 
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In regards to claim 12, Hayes and Connery discloses the system of claim 9, wherein the 
TCP stack is configured to process frames for which a special case exists (Hayes p. 39 discloses 
returning frames from the offload to the TCP stack if a special case exists.). 

In regards to claim 15, Hayes discloses receiving additional frames while uploading 
processed frames. Frames will continue to be received unless the input buffer is full. Only then 
will incoming packets be denied, i.e. dropped. Therefore it is inherent that the offload processor 
will continue to receive frames that will wait processing while it completes processing of its 
current frame. 

In regards to claim 16, Hayes discloses a method of processing frames for delegated and 
nondelegated TCP connection, comprising: processing delegated TCP connections using an 
offload unit (figs. 7 and 12 disclose an offload processor. Paragraph 38 discloses offloading a 
portion of the frames from a delegated connection for processing.) for which special cases do not 
exist (Hayes p. 39 discloses returning frames from the offload to the main processor if a special 
case exists. In other words the offload unit only processes frames for which a special cases does 
not exist) to produce processed frame data; processing non-delegated TCP connections using a 
TCP stack executing on a CPU (p. 67 discloses there are some processes, such as application 
specific initialization which should not be processed by the offload unit but instead processed 
conventionally.); processing all frames for which special cases exist using the TCP stack 
executing on the CPU (Hayes p. 39 discloses returning frames from the offload to the TCP stack 
if a special case exists.). 

Hayes does not disclose uploading the processed frame data to a user buffer in a first 
portion of memory that is allocated to an application program; and uploading frame data for the 
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non-delegated TCP connection to a legacy buffer in a second portion of the memory that is 
allocated to a software driver configured to communicate between the offload unit and the TCP 
stack. Additionally, Hayes is silent to receiving a user buffer descriptor specifying a location of 
a plurality of user buffers in a first portion of memory that is allocated to an application program, 
wherein each user buffer is configured to store processed frame data for the delegated TCP 
connection; and indicating in a filed of the user buffer descriptor how many of the user buffers 
store the first processed frame data for the delegated TCP connection. 

Connery discloses uploading the first processed frame data to a user buffer (fig. 4 
element 111 discloses a buffer) in a first portion of memory that is allocated to an application 
program (fig. 4 indicates the buffer, 1 1 1, is located in a higher layer managed memory. Col. 6 
lines 41-44 disclose it is an application managed memory.) and uploading the second processed 
frame data to a legacy buffer (fig. 4. 1 10 discloses a buffer) in a second portion of memory that is 
allocated to a software driver (fig. 4 indicates the buffer, 1 10, is located in a driver managed 
memory) configured to communicate between the offload unit and a TCP stack (fig. 3 discloses 
the driver layer, 54, communicates between the offload unit, 56, and a TCP stack, 52.). Connery 
discloses passing identification of a target buffer as a buffer descriptor including an address and 
length in col. 5 lines 1-6. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to upload the first and second portion to buffers in application or driver memory respectively, as 
taught by Connery, in the offloading method taught by Hayes because doing so improves the 
performance and scalability of a network, as taught by Connery in col. 3 lines 4-10. 
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Allison discloses a buffer count field in a user buffer descriptor in fig. 3 and col. 5 lines 
5 1-60. The field indicates the number of buffers which contain data. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include a buffer descriptor with count field, as taught by Allison, in the offload method taught 
by Hayes because doing so helps provide architecture capable of speeds from 10-1000 Mbps, as 
taught by Allison in col. 2 lines 15-17. 

In regards to claim 17, Hayes and Connery disclose the method of claim 1, wherein at 
least a portion of the first processed frame data is pay load data (Connery fig. 4.102 discloses the 
first portion consists of payload data. 

6. In regards to claims 19 and 20, Hayes discloses updating connection state information in 
paragraphs 57 and 67. 

7. Claims 26, 28, and 29 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hayes (US 2003/0158906) in view of Connery et al. (US 6,246,683) further in view of Allison et 
al. (US 6393,457) in view of known prior art. 

8. In regards to claim 26, Hayes and Connery modified by Allison disclose the method of 
claim 1 , but are silent further comprising determining that a sync request flag is not asserted, the 
sync request flag controlling flushing of existing user buffer descriptors for user buffers that do 
not store processed frame data and discarding of new user buffer descriptors for the delegated 
TCP connection that are received while the sync request flag is asserted. 

Sync is a well known function in the art. The programming language UNIX, developed 
in 1969, includes a function titled sync. This function helps ensures multiple copies of a 
database are identical by flushing any existing but unused entries. While the sync function is 
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operating new information cannot be written to the database to prevent interference with the sync 
operation. A similar function is used in many other applications. For example, Microsoft 
Outlook 2001 includes a sync function. A user may access email from Outlook or a web 
interface from a desktop, laptop, or mobile device. Any changes made, regardless of application 
and device used, are maintained across all devices using the sync function. The sync function is 
also used by other applications such as an iPod and Windows Media Player, again to ensure 
copies of the database are the same at all locations. New entries are added and old, unused, or 
deleted entries are removed. 

Official Notice is taken that it would have been obvious to one of ordinary skill in the art 
at the time of the invention to include a sync request flag, as was known in the art, in the offload 
method taught by Hayes and Connery modified by Allison because doing so ensures the database 
of buffers in use remains consistent between the main and offload units. 
9. In regards to claim 28, Hayes and Connery modified by Allison disclose the system of 
claim 9, but are silent further comprising determining that a sync request flag is not asserted, the 
sync request flag controlling flushing of existing user buffer descriptors for user buffers that do 
not store processed frame data and discarding of new user buffer descriptors for the delegated 
TCP connection that are received while the sync request flag is asserted. 

Sync is a well known function in the art. The programming language UNIX, developed 
in 1969, includes a function titled sync. This function helps ensures multiple copies of a 
database are identical by flushing any existing but unused entries. While the sync function is 
operating new information cannot be written to the database to prevent interference with the sync 
operation. A similar function is used in many other applications. For example, Microsoft 
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Outlook 2001 includes a sync function. A user may access email from Outlook or a web 
interface from a desktop, laptop, or mobile device. Any changes made, regardless of application 
and device used, are maintained across all devices using the sync function. The sync function is 
also used by other applications such as an iPod and Windows Media Player, again to ensure 
copies of the database are the same at all locations. New entries are added and old, unused, or 
deleted entries are removed. 

Official Notice is taken that it would have been obvious to one of ordinary skill in the art 
at the time of the invention to include a sync request flag, as was known in the art, in the offload 
method taught by Hayes and Conncry modified by Allison because doing so ensures the database 
of buffers in use remains consistent between the main and offload units. 
10. In regards to claim 29, Hayes and Connery modified by Allison disclose the method of 
claim 16, but are silent further comprising determining that a sync request flag is not asserted, 
the sync request flag controlling flushing of existing user buffer descriptors for user buffers that 
do not store processed frame data and discarding of new user buffer descriptors for the delegated 
TCP connection that are received while the sync request flag is asserted. 

Sync is a well known function in the art. The programming language UNIX, developed 
in 1969, includes a function titled sync. This function helps ensures multiple copies of a 
database are identical by flushing any existing but unused entries. While the sync function is 
operating new information cannot be written to the database to prevent interference with the sync 
operation. A similar function is used in many other applications. For example, Microsoft 
Outlook 2001 includes a sync function. A user may access email from Outlook or a web 
interface from a desktop, laptop, or mobile device. Any changes made, regardless of application 
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and device used, are maintained across all devices using the sync function. The sync function is 
also used by other applications such as an iPod and Windows Media Player, again to ensure 
copies of the database are the same at all locations. New entries are added and old, unused, or 
deleted entries are removed. 

Official Notice is taken that it would have been obvious to one of ordinary skill in the art 
at the time of the invention to include a sync request flag, as was known in the art, in the offload 
method taught by Hayes and Connery modified by Allison because doing so ensures the database 
of buffers in use remains consistent between the main and offload units. 

1 1 . Claims 27 and 30 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over Hayes 
(US 2003/0158906) in view of Connery et al. (US 6,246,683) further in view of Allison et al. 
(US 6393,457) in view of Dunlap et al. (US 6,760,799). 

12. In regards to claim 27, Hayes and Connery modified by Allison discloses the method of 
claim 1, but is silent further comprising: determining that a threshold value specified for a 
delegated TCP connection is exceeded; and setting a flag in a notification field indicating that the 
threshold value is exceeded for the delegated TCP connection. 

Dunlap discloses monitoring a queue level and if the threshold is exceeded setting an 
"Interrupt Now" flag for notification in col. 7 lines 17-23. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to modify the offload unit of Hayes to include the threshold and notification taught by Dunlap 
because doing so avoids multiple interrupts, as taught by Dunlap in col. 3 lines 10-22. 

13. In regards to claim 30, Hayes and Connery modified by Allison discloses the method of 
claim 16, but is silent further comprising: determining that a threshold value specified for a 
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delegated TCP connection is exceeded; and setting a flag in a notification field indicating that the 
threshold value is exceeded for the delegated TCP connection. 

Dunlap discloses monitoring a queue level and if the threshold is exceeded setting an 
"Interrupt Now" flag for notification in col. 7 lines 17-23. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to modify the offload unit of Hayes to include the threshold and notification taught by Dunlap 
because doing so avoids multiple interrupts, as taught by Dunlap in col. 3 lines 10-22. 



Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to KERRI M. ROSE whose telephone number is (571) 272-0542. 
The examiner can normally be reached on Monday through Thursday, 7:00 am - 4:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Aung MOE can be reached on (571) 272-73 14. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 



Application/Control Number: 1 0/73 1 ,632 Page 1 5 

Art Unit: 2416 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Kerri M Rose/ 
Examiner, Art Unit 2416 



/Aung S. Moe/ 

Supervisory Patent Examiner, Art Unit 2416 



